home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group93a.txt
/
000117_icon-group-sender _Sun Apr 4 21:20:33 1993.msg
< prev
next >
Wrap
Internet Message Format
|
1993-04-21
|
2KB
Received: by cheltenham.cs.arizona.edu; Mon, 12 Apr 1993 11:01:54 MST
Date: 4 Apr 93 21:20:33 GMT
From: pipex!marble.uknet.ac.uk!mcsun!news.funet.fi!uta!jere@uunet.uu.net (Jere K{pyaho)
Organization: University of Tampere, Finland
Subject: Re: Icon rookie problems solved
Message-Id: <9394@kielo.uta.fi>
References: <9364@kielo.uta.fi>, <1993Apr2.150623.19869@midway.uchicago.edu>
Sender: icon-group-request@cs.arizona.edu
To: icon-group@cs.arizona.edu
Status: R
Errors-To: icon-group-errors@cs.arizona.edu
In article <1993Apr2.150623.19869@midway.uchicago.edu> goer@midway.uchicago.edu writes:
>The key to scanning is that scanning handles all of your place-
>keeping for you, so you don't have to use "every" or the like.
>When I tab( upto(c) ), then the first result produced by upto(c)
>is where I tab to, and that becomes my position (my &pos, in Icon's
>terms). If I want the next c, I can just move(1) past the current
>c, and then do another tab( upto(c) ). Icon knows where I am in
>the string, and I don't have to keep track of it myself. The next
>time I tab( upto(c) ) I'll end up at the next match!
This is a very lucid explanation of scanning. I wasn't quite sure
about what was going on, but now I think I'm a little more educated
in this respect. Thanks.
> every i := upto(c)
I wanted to use an intermediate variable so as to make things
clearer (i.e., not to write a thoroughly compact -- and possibly
obscure -- expression.)
As Beth Weiss pointed out, we are not really *generating* here.
I congratulate myself for coming up with another solution that
uses suspend not long after I posted my initial solution.
It seems that there are quite many ways of achieving things
in Icon. The language caters for a wide spectrum of programming
styles, which is good. Many idioms of Icon initially seem very
obscure to the uninitiated. Of course, they start to make sense
fairly quickly. Then again, you can write incomprehensible code
in any programming language, including Icon. But I'll happily
choose Icon over C for any task concerned with string processing
and even primitive database work (Icon is probably suitable
for much more sophisticated database programming, but I'm only
familiar with the primitive variant :-)
--
// Jere K{pyaho (jere@kielo.uta.fi) | Work is the curse of the
// University of Tampere, Finland | drinking classes. -Oscar Wilde